You can try these changes here

Correction to my follow-up review (point #1). @live1206 rightly pointed out that RequestHeaderExtensions is a TypeProvider — PipelineRequestHeadersExtensionsDefinition (ScmOutputLibrary.cs:90) — not a raw static file. My "there's no provider to mark" reasoning was wrong; please disregard it.

The real reason the textual .SetDelimited( scan / IsRequestHeadersExtensionsFile special-case is needed is different: the only reference to this provider is the request.Headers.SetDelimited(...) call emitted inside RestClientProvider method bodies, and the provider reference graph builds edges from provider metadata (signatures, properties, fields, attributes, declared helper/body deps) — not from arbitrary method-body expressions. RestClientProvider doesn't declare PipelineRequestHeadersExtensions via BuildHelperDependencyNames / BuildBodyDependencyTypes / IncludeGeneratedBodyReferences, so the graph can't see the body-level usage and the file falls back to the string scan.

So the same marker mechanism you introduced for ClientUriBuilder (IncludeGeneratedBodyReferences) could likely subsume this last special-case: have RestClientProvider declare PipelineRequestHeadersExtensions as a helper/body dependency — ideally conditionally, only when a create-request method actually emits SetDelimited — so the graph roots it precisely and the .SetDelimited( scan + HasCustomRequestHeaderExtensionsReference handling can be dropped from the MTG core. Not blocking, just noting it's the same class of body-reference gap the rest of the PR already handles via markers, so it'd be nice to make it consistent rather than a textual exception.

--generated by Copilot

Design suggestion: derive body references from expression trees rather than declared deps + source re-parsing

Following up on the body-reference discussion — the current approach builds graph edges from provider metadata (signatures, properties, fields, attributes, etc.) and then compensates for body-level references three ways: manually-declared HelperDependencyNames / BodyDependencyTypes / IncludeGeneratedBodyReferences, AddGeneratedBodyReferences re-parsing generated source with Roslyn for a curated set of "candidate" providers, and hardcoded fallbacks (the SetDelimited scan, ChangeTracking helper roots, etc.).

The concern is soundness: a pure-metadata graph is an under-approximation of reachability, because a C# type reference can appear anywhere a method body can (new Helper(), SomeStatic.Call(), extension calls like request.Headers.SetDelimited(...), casts, typeof). For a removal/internalization pass, under-approximating is the dangerous direction — you conclude "nothing references X," internalize/remove it, and the break surfaces later as a downstream compile error or a silent public-API regression. Correctness then rests on provider authors remembering to declare every body dependency (a manually-maintained parallel list that will drift) plus the hand-curated candidate list.

Suggestion: walk the body expression trees instead. The bodies already exist as structured MethodBodyStatement / ValueExpression trees before they're rendered to source. Traversing those to collect CSharpType references (constructor targets, static member owners, type literals, generic args, cast targets) would be:

• sound by construction for anything the generator itself emits — it closes the gap generically instead of per-provider declaration, and would subsume the SetDelimited special-case and most BodyDependencyTypes/HelperDependencyNames overrides;
• likely cheaper than AddGeneratedBodyReferences re-parsing generated C# through a Roslyn semantic model.

The fact that the PR re-parses generated source for the client/serialization candidates (rather than walking expression trees) suggests the tree walk wasn't feasible for all bodies — presumably where bodies are raw TypeProvider source or interpolated string literals whose contents aren't structured ValueExpressions. If so, that's the honest residual limitation to document: expression-tree walking would handle the structured majority soundly, with a narrow, explicit fallback (or a CI superset-check against the existing full Roslyn map) for the unstructured remainder — instead of today's broader reliance on manual declarations + name-based special-cases.

Not a merge blocker, but I think it's the change that would turn this from "correct-by-testing" into "correct-by-construction." Would also be worth attributing how much of the ~21% comes from skipping body analysis vs. from pre-write internalization (skipping the Roslyn InternalizeAsync/reduce passes) — if it's mostly the latter, a sound full-body map may retain most of the win.

--generated by Copilot

latest regen: Azure/azure-sdk-for-net#60965 (comment)

Reran the PR's full-generation benchmark three times at the documented benchmark revision 4cf86686e.

Environment: Windows 11, .NET 10.0.10, 13th Gen Intel Core i7-13700T. The benchmark fixture lookup required an uncommitted Windows-only path-separator normalization; the measured workload and off/on implementations were unchanged.

Run 2's off measurement is visibly noisy, but every pass confirms a substantial time improvement and the allocation reduction is stable at 54-57%.

--generated by Copilot